Component-Based APIs for Versioning and Distributed Applications

54 Computer O perating system application programming interfaces (APIs) are typically monolithic procedural interfaces that address a single machine's requirements. This design limits evolutionary development and complicates application development for distributed systems. An OS's functionality will change over its lifetime, and these changes must be reflected in the API. In an ideal world, obsolete API calls would be deleted, and calls with modified semantics (but unmodified parameters and return values) would remain the same. Unfortunately, since the OS must continue to support legacy applications, obsolete calls can never be deleted, and new call semantics are best introduced through new calls. The need for backward compatibility leads to bloat in the API and the supporting code. In addition, typical OS APIs do not adequately address the needs of distributed applications: They have support for intermachine communication but lack high-level support for accessing remote OS resources. The primary omission is a uniform method for naming remote resources, such as windows, files, and synchronization objects. Component software methods, which have been primarily motivated by the desire for reuse, can eliminate these weaknesses. Software components are " binary units of independent production, acquisition, and deployment that interact to form a functioning system. " 1 Component software environments are largely based on distributed platforms and, due to natural software evolution typically contain multiple active versions of components. Component infra-structures therefore have good distributed computing support and also have versioning support for managing multiple versions of code. A component-based OS API is constructed entirely of software components, each modeling an OS resource. To facilitate independence, components necessarily encapsulate state and functionality. The component modeling an OS resource will therefore contain all necessary access and manipulation functions. This encapsulation allows the OS resource to be instantiated on a remote machine and also provides a natural unit for API versioning. Only the API must be component-based. The underlying OS can be monolithic, a microkernel, or component based. A component-based API controls access to the OS, which is sufficient to provide API version-ing and to expose OS resources outside the host machine (remoting). Our component-based OS proxy (COP), a prototype component-based API, acts like a traffic cop, directing OS requests to the appropriate version or resource location. COP currently targets the Win32 API and is implemented on top of Windows NT 4.0, covering approximately 350 Win32 calls. COP introduces a minimum of overhead in the local case while providing …